SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>TCP offload engine</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">TCP offload engine</span></span>

</h1>

</header>

<p><b>TCP offload engine</b> (<b>TOE</b>) is a technology used in some <a href="Network_interface_card" class="mw-redirect" title="Network interface card">network interface cards</a> (NIC) to <a href="Computation_offloading" title="Computation offloading">offload</a> processing of the entire <a href="TCP/IP" class="mw-redirect" title="TCP/IP">TCP/IP</a> stack to the network controller. It is primarily used with high-speed network interfaces, such as <a href="Gigabit_Ethernet" title="Gigabit Ethernet">gigabit Ethernet</a> and <a href="10_Gigabit_Ethernet" title="10 Gigabit Ethernet">10 Gigabit Ethernet</a>, where processing overhead of the network stack becomes significant.

TOEs are often used<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> as a way to reduce the overhead associated with <a href="Internet_Protocol" title="Internet Protocol">Internet Protocol</a> (IP) storage protocols such as <a href="ISCSI" title="ISCSI">iSCSI</a> and <a href="Network_File_System" title="Network File System">Network File System</a> (NFS).

</p>

<div class="mw-heading mw-heading2"><h2 id="Purpose">Purpose</h2></div>

<p>Originally <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a> was designed for unreliable low speed networks (such as early <a href="Dial-up" class="mw-redirect" title="Dial-up">dial-up</a> <a href="Modem" title="Modem">modems</a>) but with the growth of the Internet in terms of <a href="Internet_backbone" title="Internet backbone">backbone</a> transmission speeds (using <a href="Optical_Carrier" class="mw-redirect" title="Optical Carrier">Optical Carrier</a>, <a href="Gigabit_Ethernet" title="Gigabit Ethernet">Gigabit Ethernet</a> and <a href="10_Gigabit_Ethernet" title="10 Gigabit Ethernet">10 Gigabit Ethernet</a> links) and faster and more reliable access mechanisms (such as <a href="Digital_subscriber_line" title="Digital subscriber line">DSL</a> and <a href="Cable_modem" title="Cable modem">cable modems</a>) it is frequently used in <a href="Data_center" title="Data center">data centers</a> and desktop <a href="Personal_computer" title="Personal computer">PC</a> environments at speeds of over 1 Gigabit per second. At these speeds the TCP software implementations on host systems require significant computing power. In the early 2000s, full-duplex gigabit TCP communication could consume more than 80% of a 2.4 GHz <a href="Pentium_4" title="Pentium 4">Pentium 4</a> processor,<sup id="cite_ref-Foong_2-0" class="reference"><a href="#cite_note-Foong-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> resulting in small or no processing resources left for the applications to run on the system.

</p><p>TCP is a <a href="Connection-oriented_protocol" class="mw-redirect" title="Connection-oriented protocol">connection-oriented protocol</a> which adds complexity and processing overhead. These aspects include:

</p>

<ul><li><a href="Transmission_Control_Protocol#Connection_establishment" title="Transmission Control Protocol">Connection establishment</a> using the "3-way handshake" (SYNchronize; SYNchronize-ACKnowledge; ACKnowledge).</li>

<li>Acknowledgment of packets as they are received by the far end, adding to the message flow between the endpoints and thus the protocol load.</li>

<li><a href="Checksum" title="Checksum">Checksum</a> and sequence number calculations - again a burden on a general purpose CPU to perform.</li>

<li><a href="Sliding_window" class="mw-redirect" title="Sliding window">Sliding window</a> calculations for packet acknowledgement and <a href="Congestion_control" class="mw-redirect" title="Congestion control">congestion control</a>.</li>

<li><a href="Transmission_Control_Protocol" title="Transmission Control Protocol">Connection termination</a>.</li></ul>

<p>Moving some or all of these functions to dedicated hardware, a TCP offload engine, frees the system's main <a href="CPU" class="mw-redirect" title="CPU">CPU</a> for other tasks.

</p>

<div class="mw-heading mw-heading3"><h3 id="Freed-up_CPU_cycles">Freed-up CPU cycles</h3></div>

<p>A generally accepted rule of thumb is that 1 Hertz of CPU processing is required to send or receive <span class="nowrap">1 <a href="Bit_per_second" class="mw-redirect" title="Bit per second">bit/s</a></span> of TCP/IP.<sup id="cite_ref-Foong_2-1" class="reference"><a href="#cite_note-Foong-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> For example, 5 Gbit/s (625 MB/s) of network traffic requires 5 GHz of CPU processing. This implies that 2 entire cores of a 2.5 GHz <a href="Multi-core_processor" title="Multi-core processor">multi-core processor</a> will be required to handle the TCP/IP processing associated with 5 Gbit/s of TCP/IP traffic. Since Ethernet (10GE in this example) is bidirectional, it is possible to send and receive 10 Gbit/s (for an aggregate throughput of 20 Gbit/s). Using the 1 Hz/(bit/s) rule this equates to eight 2.5 GHz cores.

</p><p>Many of the CPU cycles used for TCP/IP processing are <i>freed-up</i> by TCP/IP offload and may be used by the CPU (usually a <a href="Server_(computing)" title="Server (computing)">server</a> CPU) to perform other tasks such as file system processing (in a file server) or indexing (in a backup media server). In other words, a server with TCP/IP offload can do more <b>server</b> work than a server without TCP/IP offload NICs.

</p>

<div class="mw-heading mw-heading3"><h3 id="Reduction_of_PCI_traffic">Reduction of PCI traffic</h3></div>

<p>In addition to the protocol overhead that TOE can address, it can also address some architectural issues that affect a large percentage of host based (server and PC) endpoints.

Many older end point hosts are <a href="Peripheral_Component_Interconnect" title="Peripheral Component Interconnect">PCI</a> bus based, which provides a standard interface for the addition of certain <a href="Peripherals" class="mw-redirect" title="Peripherals">peripherals</a> such as Network Interfaces to <a href="Server_(computing)" title="Server (computing)">Servers</a> and PCs.

PCI is inefficient for transferring small bursts of data from main memory, across the PCI bus to the network interface ICs, but its efficiency improves as the data burst size increases. Within the TCP protocol, a large number of small packets are created (e.g. acknowledgements) and as these are typically generated on the host CPU and transmitted across the PCI bus and out the network physical interface, this impacts the host computer IO throughput.

</p><p>A TOE solution, located on the network interface, is located on the other side of the PCI bus from the CPU host so it can address this I/O efficiency issue, as the data to be sent across the TCP connection can be sent to the TOE from the CPU across the PCI bus using large data burst sizes with none of the smaller TCP packets having to traverse the PCI bus.

</p>

<div class="mw-heading mw-heading2"><h2 id="History">History</h2></div>

<p>One of the first patents in this technology, for UDP offload, was issued to <a href="Auspex_Systems" title="Auspex Systems">Auspex Systems</a> in early 1990.<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup> Auspex founder Larry Boucher and a number of Auspex engineers went on to found Alacritech in 1997 with the idea of extending the concept of network stack offload to TCP and implementing it in custom silicon. They introduced the first parallel-stack full offload network card in early 1999; the company's SLIC (Session Layer Interface Card) was the predecessor to its current TOE offerings. Alacritech holds a number of patents in the area of TCP/IP offload.<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p><p>By 2002, as the emergence of TCP-based storage such as <a href="ISCSI" title="ISCSI">iSCSI</a> spurred interest, it was said that "At least a dozen newcomers, most founded toward the end of the dot-com bubble, are chasing the opportunity for merchant semiconductor accelerators for storage protocols and applications, vying with half a dozen entrenched vendors and in-house ASIC designs."<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup>

</p><p>In 2005 <a href="Microsoft" title="Microsoft">Microsoft</a> licensed Alacritech's patent base and along with Alacritech created the partial TCP offload architecture that has become known as TCP chimney offload. TCP chimney offload centers on the Alacritech "Communication Block Passing Patent". At the same time, Broadcom also obtained a license to build TCP chimney offload chips.

</p>

<div class="mw-heading mw-heading2"><h2 id="Types">Types</h2></div>

<p>Instead of replacing the TCP stack with a TOE entirely, there are alternative techniques to offload some operations in co-operation with the operating system's TCP stack. <a href="TCP_checksum_offload" class="mw-redirect" title="TCP checksum offload">TCP checksum offload</a> and <a href="Large_segment_offload" class="mw-redirect" title="Large segment offload">large segment offload</a> are supported by the majority of today's Ethernet NICs. Newer techniques like <a href="Large_receive_offload" class="mw-redirect" title="Large receive offload">large receive offload</a> and TCP acknowledgment offload are already implemented in some high-end Ethernet hardware, but are effective even when implemented purely in software.<sup id="cite_ref-lwn-lro_6-0" class="reference"><a href="#cite_note-lwn-lro-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-menon_7-0" class="reference"><a href="#cite_note-menon-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Parallel-stack_full_offload">Parallel-stack full offload</h3></div>

<p>Parallel-stack full offload gets its name from the concept of two parallel TCP/IP Stacks. The first is the main host stack which is included with the host OS. The second or "parallel stack" is connected between the <a href="Internet_protocol_suite#Application_layer" title="Internet protocol suite">Application Layer</a> and the <a href="Internet_protocol_suite#Transport_layer" title="Internet protocol suite">Transport Layer (TCP)</a> using a "vampire tap". The vampire tap intercepts TCP connection requests by applications and is responsible for TCP connection management as well as TCP data transfer. Many of the criticisms in the following section relate to this type of TCP offload.

</p>

<div class="mw-heading mw-heading3"><h3 id="HBA_full_offload">HBA full offload</h3></div>

<p>HBA (Host Bus Adapter) full offload is found in iSCSI <a href="Host_adapter" title="Host adapter">host adapters</a> which present themselves as disk controllers to the host system while connecting (via TCP/IP) to an <a href="ISCSI" title="ISCSI">iSCSI</a> storage device. This type of TCP offload not only offloads TCP/IP processing but it also offloads the iSCSI initiator function. Because the HBA appears to the host as a disk controller, it can only be used with iSCSI devices and is not appropriate for general TCP/IP offload.

</p>

<div class="mw-heading mw-heading3"><h3 id="TCP_chimney_partial_offload">TCP chimney partial offload</h3></div>

<p>TCP chimney offload addresses the major security criticism of parallel-stack full offload. In partial offload, the main system stack controls all connections to the host. After a connection has been established between the local host (usually a server) and a foreign host (usually a client) the connection and its state are passed to the TCP offload engine. The heavy lifting of data transmit and receive is handled by the offload device. Almost all TCP offload engines use some type of TCP/IP hardware implementation to perform the data transfer without host CPU intervention. When the connection is closed, the connection state is returned from the offload engine to the main system stack. Maintaining control of TCP connections allows the main system stack to implement and control connection security.

</p>

<div class="mw-heading mw-heading3"><h3 id="Large_receive_offload">Large receive offload</h3></div>

<p><b>Large receive offload</b> (<b>LRO</b>) is a technique for increasing inbound <a href="Throughput" class="mw-redirect" title="Throughput">throughput</a> of high-<a href="Bandwidth_(computing)" title="Bandwidth (computing)">bandwidth</a> network connections by reducing <a href="Central_processing_unit" title="Central processing unit">central processing unit</a> (CPU) overhead. It works by aggregating multiple incoming <a href="Packet_(information_technology)" class="mw-redirect" title="Packet (information technology)">packets</a> from a single <a href="Stream_(computing)" title="Stream (computing)">stream</a> into a larger buffer before they are passed higher up the networking stack, thus reducing the number of packets that have to be processed. <a href="Linux" title="Linux">Linux</a> implementations generally use LRO in conjunction with the <a href="New_API" title="New API">New API</a> (NAPI) to also reduce the number of <a href="Interrupt" title="Interrupt">interrupts</a>.

</p><p>According to benchmarks, even implementing this technique entirely in software can increase network performance significantly.<sup id="cite_ref-lwn-lro_6-1" class="reference"><a href="#cite_note-lwn-lro-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-menon_7-1" class="reference"><a href="#cite_note-menon-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-8" class="reference"><a href="#cite_note-8"><span class="cite-bracket">[</span>8<span class="cite-bracket">]</span></a></sup> As of April 2007, the <a href="Linux_kernel" title="Linux kernel">Linux kernel</a> supports LRO for <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a> in software only. <a href="FreeBSD" title="FreeBSD">FreeBSD</a> 8 supports LRO in hardware on adapters that support it.<sup id="cite_ref-9" class="reference"><a href="#cite_note-9"><span class="cite-bracket">[</span>9<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-10" class="reference"><a href="#cite_note-10"><span class="cite-bracket">[</span>10<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-11" class="reference"><a href="#cite_note-11"><span class="cite-bracket">[</span>11<span class="cite-bracket">]</span></a></sup>

</p><p>LRO should not operate on machines acting as routers, as it breaks the <a href="End-to-end_principle" title="End-to-end principle">end-to-end principle</a> and can significantly impact performance.<sup id="cite_ref-13" class="reference"><a href="#cite_note-13"><span class="cite-bracket">[</span>13<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-14" class="reference"><a href="#cite_note-14"><span class="cite-bracket">[</span>14<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading4"><h4 id="Generic_receive_offload">Generic receive offload</h4></div>

<p><b>Generic receive offload</b> (<b>GRO</b>) implements a generalised LRO in software that isn't restricted to TCP/<a href="IPv4" title="IPv4">IPv4</a> or have the issues created by LRO.<sup id="cite_ref-15" class="reference"><a href="#cite_note-15"><span class="cite-bracket">[</span>15<span class="cite-bracket">]</span></a></sup><sup id="cite_ref-16" class="reference"><a href="#cite_note-16"><span class="cite-bracket">[</span>16<span class="cite-bracket">]</span></a></sup>

</p>

<div class="mw-heading mw-heading3"><h3 id="Large_send_offload">Large send offload</h3></div>

<p>In <a href="Computer_network" title="Computer network">computer networking</a>, <b>large send offload</b> (<b>LSO</b>) is a technique for increasing egress <a href="Throughput" class="mw-redirect" title="Throughput">throughput</a> of high-<a href="Bandwidth_(computing)" title="Bandwidth (computing)">bandwidth</a> network connections by reducing <a href="Central_processing_unit" title="Central processing unit">CPU</a> overhead. It works by passing a multipacket buffer to the <a href="Network_interface_card" class="mw-redirect" title="Network interface card">network interface card</a> (NIC). The NIC then splits this buffer into separate packets. The technique is also called <b>TCP segmentation offload</b> (<b>TSO</b>) or <b>generic segmentation offload</b> (<b>GSO</b>) when applied to <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a>. LSO and LRO are independent and use of one does not require the use of the other.

</p><p>When a system needs to send large chunks of data out over a computer network, the chunks first need breaking down into smaller segments that can pass through all the network elements like routers and switches between the source and destination computers. This process is referred to as <i><a href="Packet_segmentation" title="Packet segmentation">segmentation</a></i>. Often the TCP protocol in the host computer performs this segmentation. Offloading this work to the NIC is called <i>TCP segmentation offload</i> (TSO).

</p><p>For example, a unit of 64 KiB (65,536 bytes) of data is usually segmented to 45 segments of 1460 bytes each before it is sent through the NIC and over the network. With some intelligence in the NIC, the host CPU can hand over the 64 KB of data to the NIC in a single transmit-request, the NIC can break that data down into smaller segments of 1460 bytes, add the TCP, <a href="Internet_Protocol" title="Internet Protocol">IP</a>, and data link layer protocol headers — according to a template provided by the host's TCP/IP stack — to each segment, and send the resulting frames over the network. This significantly reduces the work done by the CPU. As of 2014 many new NICs on the market support TSO.

</p><p>Some network cards implement TSO generically enough that it can be used for offloading fragmentation of other <a href="Transport_layer" title="Transport layer">transport layer</a> protocols, or for doing <a href="IP_fragmentation" title="IP fragmentation">IP fragmentation</a> for protocols that don't support fragmentation by themselves, such as <a href="User_Datagram_Protocol" title="User Datagram Protocol">UDP</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Support_in_Linux">Support in Linux</h2></div>

<p>Unlike other operating systems, such as FreeBSD, the Linux kernel does not include support for TOE (not to be confused with other types of network offload).<sup id="cite_ref-17" class="reference"><a href="#cite_note-17"><span class="cite-bracket">[</span>17<span class="cite-bracket">]</span></a></sup> While there are patches from the hardware manufacturers such as <a href="Chelsio" class="mw-redirect" title="Chelsio">Chelsio</a> or <a href="Qlogic" class="mw-redirect" title="Qlogic">Qlogic</a> that add TOE support, the Linux kernel developers are opposed to this technology for several reasons:<sup id="cite_ref-18" class="reference"><a href="#cite_note-18"><span class="cite-bracket">[</span>18<span class="cite-bracket">]</span></a></sup>

</p>

<ul><li><i>Security</i> – because TOE is implemented in hardware, patches must be applied to the TOE <a href="Firmware" title="Firmware">firmware</a>, instead of just software, to address any security vulnerabilities found in a particular TOE implementation. This is further compounded by the newness and vendor-specificity of this hardware, as compared to a well tested TCP/IP stack as is found in an operating system that does not use TOE.</li>

<li><i>Limitations</i> of hardware – because connections are buffered and processed on the TOE chip, resource starvation can more easily occur as compared to the generous CPU and memory available to the operating system.</li>

<li><i>Complexity</i> – TOE breaks the assumption that kernels make about having access to all resources at all times – details such as memory used by open connections are not available with TOE. TOE also requires very large changes to a networking stack in order to be supported properly, and even when that is done, features like <a href="Quality_of_service" title="Quality of service">quality of service</a> and <a href="Packet_filtering" class="mw-redirect" title="Packet filtering">packet filtering</a> might not work.</li>

<li><i>Proprietary</i> – TOE is implemented differently by each hardware vendor. This means more code must be rewritten to deal with the various TOE implementations, at a cost of the aforementioned complexity and, possibly, security. Furthermore, TOE firmware cannot be easily modified since it is closed-source.</li>

<li><i>Obsolescence</i> – Each TOE NIC has a limited lifetime of usefulness, because system hardware rapidly catches up to TOE performance levels, and eventually exceeds TOE performance levels.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Suppliers">Suppliers</h2></div>

<p>Much of the current work on TOE technology is by manufacturers of 10 Gigabit Ethernet interface cards, such as <a href="Broadcom" title="Broadcom">Broadcom</a>, <a href="Chelsio_Communications" title="Chelsio Communications">Chelsio Communications</a>, <a href="Emulex" title="Emulex">Emulex</a>, <a href="Mellanox_Technologies" title="Mellanox Technologies">Mellanox Technologies</a>, <a href="QLogic" title="QLogic">QLogic</a>.

</p>

<ul><li><a href="Scalable_Networking_Pack" title="Scalable Networking Pack">Scalable Networking Pack</a></li>

<li><a href="I/O_Acceleration_Technology" title="I/O Acceleration Technology">I/O Acceleration Technology</a> (I/OAT)</li>

<li><a href="Energy-Efficient_Ethernet" title="Energy-Efficient Ethernet">Energy-Efficient Ethernet</a> (EEE)</li>

<li><a href="Autonomous_peripheral_operation" title="Autonomous peripheral operation">Autonomous peripheral operation</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist reflist-columns references-column-width" style="column-width: 30em;">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFJeffrey_C._Mogul2003" class="citation conference cs1">Jeffrey C. Mogul (2003-05-18). <a rel="nofollow" class="external text" href="https://www.usenix.org/conference/hotos-ix/tcp-offload-dumb-idea-whose-time-has-come"><i>TCP Offload Is a Dumb Idea Whose Time Has Come</i></a>. HotOS. <a href="Usenix" class="mw-redirect" title="Usenix">Usenix</a>.</cite></span>

</li>

<li id="cite_note-Foong-2"><span class="mw-cite-backlink">^ <a href="#cite_ref-Foong_2-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-Foong_2-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFAnnie_P._FoongThomas_R._HuffHerbert_H._HumJaidev_P._Patwardhan2003" class="citation conference cs1">Annie P. Foong; Thomas R. Huff; Herbert H. Hum; Jaidev P. Patwardhan; Greg J. Regnier (2003-04-02). <a rel="nofollow" class="external text" href="http://www.nanogrids.org/jaidev/papers/ispass03.pdf"><i>TCP performance re-visited</i></a> <span class="cs1-format">(PDF)</span>. Proceedings of the International Symposium on Performance Analysis of Systems and Software (ISPASS). Austin, Texas.</cite></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-3">^</a></b></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5355453.PN.&OS=PN/5355453&RS=PN/5355453">United States Patent: 5355453 <i>"Parallel I/O network file server architecture category"</i></a></span>

</li>

<a rel="nofollow" class="external text" href="http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6247060.PN.&OS=PN/6247060&RS=PN/6247060">United States Patent: 6247060 <i>"Passing a Communication Block from Host to a Local Device such that a message is processed on the Device"</i></a></span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-5">^</a></b></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://www.eetimes.com/electronics-news/4143213/Newcomers-spin-storage-network-silicon">"Newcomers spin storage network silicon "</a>, Rick Merritt,

10/21/2002, EE Times</span>

</li>

<li id="cite_note-lwn-lro-6"><span class="mw-cite-backlink">^ <a href="#cite_ref-lwn-lro_6-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-lwn-lro_6-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFJonathan_Corbet2007" class="citation news cs1">Jonathan Corbet (2007-08-01). <a rel="nofollow" class="external text" href="https://lwn.net/Articles/243949/">"Large receive offload"</a>. <a href="LWN.net" title="LWN.net">LWN.net</a><span class="reference-accessdate">. Retrieved <span class="nowrap">2007-08-22</span></span>.</cite></span>

</li>

<li id="cite_note-menon-7"><span class="mw-cite-backlink">^ <a href="#cite_ref-menon_7-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-menon_7-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text"><cite id="CITEREFAravind_MenonWilly_Zwaenepoel2008" class="citation conference cs1">Aravind Menon; Willy Zwaenepoel (2008-04-28). <a rel="nofollow" class="external text" href="http://www.usenix.org/event/usenix08/tech/full_papers/menon/menon_html/paper.html"><i>Optimizing TCP Receive Performance</i></a>. USENIX Annual Technical Conference. USENIX.</cite></span>

</li>

<li id="cite_note-8"><span class="mw-cite-backlink"><b><a href="#cite_ref-8">^</a></b></span> <span class="reference-text"><cite id="CITEREFAndrew_Gallatin2007" class="citation mailinglist cs1">Andrew Gallatin (2007-07-25). <a rel="nofollow" class="external text" href="https://lkml.org/lkml/2007/7/25/313">"lro: Generic Large Receive Offload for TCP traffic"</a>. <i>linux-kernel</i> (Mailing list)<span class="reference-accessdate">. Retrieved <span class="nowrap">2007-08-22</span></span>.</cite></span>

</li>

<li id="cite_note-9"><span class="mw-cite-backlink"><b><a href="#cite_ref-9">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://www.freebsd.org/cgi/man.cgi?cxgb">"Cxgb"</a>. <i>Freebsd.org</i><span class="reference-accessdate">. Retrieved <span class="nowrap">12 July</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-10"><span class="mw-cite-backlink"><b><a href="#cite_ref-10">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://www.freebsd.org/cgi/man.cgi?mxge">"Mxge"</a>. <i>Freebsd.org</i><span class="reference-accessdate">. Retrieved <span class="nowrap">12 July</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-11"><span class="mw-cite-backlink"><b><a href="#cite_ref-11">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://www.freebsd.org/cgi/man.cgi?nxge">"Nxge"</a>. <i>Freebsd.org</i><span class="reference-accessdate">. Retrieved <span class="nowrap">12 July</span> 2018</span>.</cite></span>

</li>

<li id="cite_note-vmxnet-lro-12"><span class="mw-cite-backlink"><b><a href="#cite_ref-vmxnet-lro_12-0">^</a></b></span> <span class="reference-text"><cite class="citation news cs1"><a rel="nofollow" class="external text" href="http://kb.vmware.com/kb/1027511">"Poor TCP performance can occur in Linux virtual machines with LRO enabled"</a>. <a href="VMware" title="VMware">VMware</a>. 2011-07-04<span class="reference-accessdate">. Retrieved <span class="nowrap">2011-08-17</span></span>.</cite></span>

</li>

<li id="cite_note-13"><span class="mw-cite-backlink"><b><a href="#cite_ref-13">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20191124112839/http://downloadmirror.intel.com/14687/eng/readme.txt">"Linux* Base Driver for the Intel(R) Ethernet 10 Gigabit PCI Express Family of Adapters"</a>. <a href="Intel_Corporation" class="mw-redirect" title="Intel Corporation">Intel Corporation</a>. 2013-02-12. Archived from the original on 2019-11-24<span class="reference-accessdate">. Retrieved <span class="nowrap">2013-04-24</span></span>.</cite><span class="cs1-maint citation-comment"><code class="cs1-code">{{cite web}}</code>: CS1 maint: bot: original URL status unknown (link)</span></span>

</li>

<li id="cite_note-14"><span class="mw-cite-backlink"><b><a href="#cite_ref-14">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://bugzilla.redhat.com/show_bug.cgi?id=772317">"Disable LRO for all NICs that have LRO enabled"</a>. <a href="Red_Hat%2C_Inc." class="mw-redirect" title="Red Hat, Inc.">Red Hat, Inc.</a> 2013-01-10<span class="reference-accessdate">. Retrieved <span class="nowrap">2013-04-24</span></span>.</cite></span>

</li>

<li id="cite_note-15"><span class="mw-cite-backlink"><b><a href="#cite_ref-15">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://lwn.net/Articles/358910/">"JLS2009: Generic receive offload"</a>. <i><a href="Lwn.net" class="mw-redirect" title="Lwn.net">lwn.net</a></i>.</cite></span>

</li>

<li id="cite_note-16"><span class="mw-cite-backlink"><b><a href="#cite_ref-16">^</a></b></span> <span class="reference-text"><cite id="CITEREFHuangBaldine2012" class="citation conference cs1">Huang, Shu; Baldine, Ilia (March 2012). Schmitt, Jens B. (ed.). <a rel="nofollow" class="external text" href="https://books.google.com/books?id=C3wQBwAAQBAJ"><i>Performance Evaluation of 10GE NICs with SR-IOV Support: I/O Virtualization and network Stack Optimizations</i></a>. Measurement, Modeling, and Evaluation of Computing Systems and Dependability and Fault Tolerance: 16th International GI/ITG Conference, MMB & DFT 2012. Lecture Notes in Computer Science. Vol. 7201. Kaiserslautern, Germany: Springer (published 2012). p. 198. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9783642285400</bdi><span class="reference-accessdate">. Retrieved <span class="nowrap">2016-10-11</span></span>. <q>Large-Receive-Offload (LRO) reduces the per-packet processing overhead by aggregating smaller packets into larger ones and passing them up to the network stack. Generic-Receive-Offload (GRO) provides a generalized software version of LRO [...].</q></cite></span>

</li>

<li id="cite_note-17"><span class="mw-cite-backlink"><b><a href="#cite_ref-17">^</a></b></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://lwn.net/Articles/148697/">"Linux and TCP offload engines"</a>, August 22, 2005, LWN.net</span>

</li>

<li id="cite_note-18"><span class="mw-cite-backlink"><b><a href="#cite_ref-18">^</a></b></span> <span class="reference-text"><cite class="citation cs2"><a rel="nofollow" class="external text" href="https://wiki.linuxfoundation.org/networking/toe"><i>Networking:TOE</i></a>, Linux Foundation</cite>.</span>

</li>

</ol></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li>Article: <a rel="nofollow" class="external text" href="https://web.archive.org/web/20041028124133/http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=154">TCP Offload to the Rescue</a> by Andy Currid at <a rel="nofollow" class="external text" href="http://www.acmqueue.com/">ACM Queue</a></li>

<li><a rel="nofollow" class="external text" href="http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040042487%22.PGNR.&OS=DN/20040042487&RS=DN/20040042487">Patent Application 20040042487 </a></li>

<li><cite id="CITEREFMogul2003" class="citation conference cs1">Mogul, Jeffrey C. (2003). <a rel="nofollow" class="external text" href="http://www.usenix.org/events/hotos03/tech/full_papers/mogul/mogul.pdf">"TCP offload is a dumb idea whose time has come"</a> <span class="cs1-format">(PDF)</span>. <i>Proceedings of HotOS IX: The 9th Workshop on Hot Topics in Operating Systems</i>. USENIX Association<span class="reference-accessdate">. Retrieved <span class="nowrap">23 July</span> 2006</span>.</cite></li>

<li><cite class="citation web cs1"><a rel="nofollow" class="external text" href="http://line-provider.com/whitepapers/tcpip-offload-engine-toe/">"TCP/IP offload Engine (TOE)"</a>. <a href="10_Gigabit_Ethernet_Alliance" title="10 Gigabit Ethernet Alliance">10 Gigabit Ethernet Alliance</a>. April 2002.</cite></li>

<li><a rel="nofollow" class="external text" href="https://docs.microsoft.com/en-us/windows-hardware/drivers/network/offloading-the-segmentation-of-large-tcp-packets">Windows Network Task Offload</a></li>

<li><a rel="nofollow" class="external text" href="https://wiki.linuxfoundation.org/networking/gso">GSO in Linux</a></li>

<li><a rel="nofollow" class="external text" href="https://wiki.geant.org/pages/releaseview.action?pageId=121340564">Brief Description of LSO in Linux</a></li>

<li><a rel="nofollow" class="external text" href="https://wiki.geant.org/display/public/EK/Case+Studies">Case Studies of Performance issues with LSO and Traffic Shaping (Linux)</a></li>

<li><a rel="nofollow" class="external text" href="http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=1">FreeBSD 7.0 new features, brief discussion on TSO support</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20161221164032/http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=1">Archived</a> 2016-12-21 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-07-18" href="https://en.wikipedia.org/wiki/?title=TCP_offload_engine&oldid=1301079297">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>